“Multihoming” is a term used to describe the provision of multiple direct or indirect IP interfaces to a single mobile node such that the mobile node is able to send and/or receive data via any one of the interfaces. Consider for example a wireless mobile terminal belonging to a user have a subscription with a home Public Land Mobile Network (PLMN). The terminal may be allocated a fixed IP address by the home network, i.e. a Global Home Address (GHoA). When the terminal is attached to the home PLMN it is directly reachable at the GHoA. However, when the terminal is attached to a visited PLMN, the terminal will be allocated a local IP address by the visited PLMN, termed a Local Home Address (LHoA). Moreover, it is possible that the terminal may be allocated multiple GHoAs/LhoAs within the home and visited PLMNs to provide a degree of redundancy.
A mobile node can benefit from using different IP address for different purposes. However, it can be an excessive operational burden for the mobile node itself to handle IP address selection and management. First of all, the mobile node may not have knowledge of the different characteristics of different IP addresses. For example, the mobile node may be unaware that the use of a GHoA will result in tunneling of an entire traffic flow through a Global Mobility Management (GMM) Anchor in the home network, whereas the use of a LHoA will result in tunneling of the entire traffic flow through a Local Mobility Management (LMM) Anchor in the visited network. Secondly, using different IP addresses for the same communication session is not ideal from the perspective of upper layer protocols. Normally, upper layer protocols cannot change the endpoints of a communication during the lifetime of a session. Thirdly, a peer node with which a mobile node is communicating may be confused by the use of multiple IP addresses associated with a single mobile node. Whilst the peer node may be able to learn and associate the multiple IP addresses (e.g. via a DNS lookup), the peer cannot necessarily choose the correct IP address to use in a given circumstance.
A solution to the multihoming problem and which avoids the need to place additional operational requirements on the mobile node involves the use of a Network Address Translator (NAT). This approach is illustrated in FIG. 1 for the case where two communicating mobile nodes, MN1 and MN2, are attached to respective visited networks. A NAT is located within MN1's visited network, co-located with the LMM anchor, and performs address translation based upon a mapping between the GHoA and LHoA of MN1. In this way, a mobile node can continue using a single IP address for all communications while a communication can be locally broken out according to the policies of the network operator.
The NAT-based solution has its problems however. Firstly, the end-to-end nature of the Internet is broken as the NAT rewrites the IP source and/or destination IP address. This means that the communicating peers cannot utilise end-to-end security mechanism such as IPsec. Secondly, address translation (on behalf of the mobile node behind the NAT) can only be made at the initiator side and therefore the routing path cannot be fully optimised. Thirdly, it is impossible to change the Locator (i.e. the IP address used to direct traffic to the NAT) during a session lifetime because the “stateful” information is solely maintained by the NAT device. The communication is broken if the initiator changes the LMM anchor. This is important as it effectively prevents the initiator (MN1) from roaming to another LMM anchor, for example within a new access network, whilst maintaining an ongoing session. Thus, mobility protocols such as Mobile IP cannot be used efficiently with the NAT-based approach to multihoming.
Layer 3 Shim for IPv6 (SHIM6) [E. Nordmark and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” draft-ietf-shim6-proto-08.txt, work-in-progress] is a protocol which aims to facilitate multihoming of fixed nodes by adding an additional layer in the protocol stack at the host, below the transport layers. The SHIM6 layer performs a translation between an Upper Layer Identifier (ULID) which serves as a permanent communication endpoint for a node and one or more Locators which represent the topological point(s) of attachment of the node. A fourway handshake is conducted between nodes prior to employing SHIM6 in order to create a shared SHIM6 context. This context defines for both nodes the ULID-to-Locator mappings. In the event that ULIDs of both nodes represent the optimal routing path between the nodes, packets may pass transparently through the SHIM6 layers at both endpoints. However, if that is not the case (or a link fails) the SHIM6 layer at the sending node can replace the ULID for one or both of the source and destination IP addresses with one of the corresponding Locators.
A SHIM6 proxy has been proposed [M. Bagnulo, draft-bagnulo-pshim6-01, “Proxy Shim6(P-Shim6),” work-in-progress] which shifts the SHIM6 layer to a network based entity. As such, the SHIM6 proxy is responsible for establishing and maintaining a SHIM6 context with a peer node or other SHIM6 proxy. Considering again FIG. 1, one can consider replacing the NAT device in the visited PLMN with a SHIM6 proxy. The proxy would be aware of the multiple interfaces available to the peer node, MN2, and could direct traffic either to the GMM anchor of MN2 or directly to its LMM anchor. The use of a SHIM6 proxy allows route optimisation to be carried out on either side of the communication path, as the SHIM6 context is shared by both ends. This is in contrast to the NAT approach where mapping information is not shared.